A conventional virtual machine monitor (VMM) typically runs on a computer and presents to other software the abstraction of one or more virtual machines. Each virtual machine may function as a self-contained platform, running its own “guest operating system” (i.e., an operating system hosted by the VMM). The guest operating system expects to operate as if it were running on a dedicated computer rather than a virtual machine. That is, the guest operating system expects to control various computer operations and have an unlimited access to the computer's physical memory and memory-mapped I/O devices during these operations. However, in a virtual machine environment, the VMM should be able to have ultimate control over the computer's resources to provide protection from and between virtual machines. To achieve this, the VMM typically intercepts and arbitrates all accesses made by the guest operating system to the computer resources.
With existing processors (e.g., IA-32 microprocessors), the VMM may not be able to intercept accesses of the guest operating system to hardware resources unless a portion of the VMM code and/or data structures is located in the same virtual address space as the guest operating system. However, the guest operating system does not expect the VMM code and/or data structures to reside in the address space of the guest operating system and can attempt to access a region occupied by the VMM in this address space, causing an address space conflict between the guest operating system and the VMM. This conflict may result in abnormal termination of operations performed by the VMM or the guest operating system.
Thus, a mechanism is needed that will detect and resolve address space conflicts between a VMM and a guest operating system.